Authorization policies are used to control access to security-critical services in distributed environments such as computer networks. Such authorization policies can be defined using associated authorization languages, which provide flexibility and expressiveness in the policy specification. These languages allow the authorization policy to be written explicitly as a list of declarative rules.
Requests for access to security-critical services are received at a reference monitor, which is a service serving requests from user terminals. The reference monitor queries an authorization node executing the authorization policy. Access for the user is granted only if the authorization node evaluating the policy succeeds in proving that the request complies with the local policy and any current authorization state. The authorization state is a database containing relevant environmental facts including knowledge obtained from authorization credentials.
However, often the reference monitor not only allows or denies access, but also updates the authorization state after a successful request. In a role-based policy, for instance, the fact that a user has activated some role is inserted into the authorization state after a successful role activation request. Similarly, the fact can be removed from the authorization state if the role is deactivated. There are many authorization policies that depend on past interactions; relevant events are therefore stored in the authorization state.
Consider, for instance, the following policy rule (part of the authorization policy executed on the authorization node) for initiating a payment:
canInitPayment(x,p) : Bank says x is a manager, not(∃y(Bank says y has initiated p))
According to this policy fragment, if x is a manager, then x can initiate a payment p, provided that payment has not been already initiated. Therefore, the precondition for granting the action checks for the absence of ‘has initiated’ facts in the authorization state. For this scheme to work as intended, a granted payment initiation action has the side effect of inserting a ‘has initiated’ fact into the authorization state. Such effects are hard-coded into the reference monitor, for example as illustrated in pseudocode below.
handleRequests(Action a, Params ps) { if (Policy.permits(a, ps) { if (a==‘canInitPayment’) {  Policy.insert(ps[0] has initiated ps[1]); } [. . .] execute(a, ps); } [. . .]}
In the example above, a is the ‘canInitPayment’ rule defined above, ps[0] is the user x, and ps[1] is the payment p. This results in the reference monitor inserting the fact ‘x has initiated p’ into the authorization state.
As shown, updates to the authorization state use the functionality of a programming language, and are hard-coded into the reference monitor. This leads to poor maintainability, as changes to the authorization policy can result in corresponding changes being required in the compiled programs executed on the reference monitor.
The embodiments described below are not limited to implementations which solve any or all of the disadvantages of known authorization systems.